home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr27 / prindir.zip / PRINDIR.DOC < prev   
Text File  |  1993-05-24  |  10KB  |  199 lines
  1.  
  2.  
  3.  
  4.               PRINDIR - Printer Redirection Utility Documentation
  5.                                          
  6.                        Program Written by Michael A. Hotz
  7.                                          
  8.                               in association with:
  9.                                          
  10.                           Techniform Industries, Inc.
  11.                                2107 Hayes Avenue
  12.                               Fremont, Ohio  43420
  13.                                          
  14.                 Compuserve - 72200,1312          GEmail - MAHOTZ
  15.                                          
  16.        Daytime Phone  (419) 332-8484       (9 a.m. - 4 p.m. Eastern Time)
  17.        Any other time (419) 262-8322       ( if no answer leave message )
  18.                                          
  19.       
  20.           I have put a great deal of time into developing this program. My
  21.      goals when I began writing this program were simple. I wanted an
  22.      effective utility that would let me easily select the destination for
  23.      printer output. The first versions I wrote simply toggled back and
  24.      forth from screen to printer. This was o.k., however, I wanted to be
  25.      able to print to a file. I also wanted to do all of these things in as
  26.      little memory as possible.
  27.       
  28.           When I began coding the handlers to dump output to a file, I
  29.      tried many different methods. I finally came upon the way that at this
  30.      point seems to work best, and in doing so, I eliminated some of the
  31.      quirks in other printer redirection utilities I have seen and used.
  32.       
  33.           Before I continue, I would like to mention that I am releasing
  34.      this program as shareware. The requested payment is $10.00, however no
  35.      amount whether larger or smaller will be turned down. This work is
  36.      Copyright (c) 1989 by J.M. Allen Creations. All Rights Reserved by
  37.      Michael A. Hotz. The user assumes all risk which may be involved
  38.      through the use of this program. Neither Michael A. Hotz nor J.M.
  39.      Allen Creations make any warrantees, expressed or implied, as to the
  40.      usefulness or effectiveness of this program. This program may not be
  41.      disassembled, reverse engineered, or modified in any way without
  42.      express written permission from the author.
  43.       
  44.      I will be glad to offer assistance to those who request it, either by
  45.      phone, E-Mail, U.S. Mail, or whatever other means you may decide to
  46.      use to contact me.
  47.       
  48.           First of all, you must run the program from the command line (DOS
  49.      2.0 or greater please!) with the proper argument to install it in
  50.      memory. The program requires one argument which will determine where
  51.      in memory it will use a 28k buffer for redirection to a file. The
  52.      program will explain this when you run it, however I will detail these
  53.      options more clearly here.
  54.       
  55.           If you argument /m, the program will assume you have a monochrome
  56.      video adapter with AT LEAST 32k of display memory beginning at segment
  57.      B000h. The program will then start it's buffer on page two of your
  58.      video ram, effectively saving conventional memory. In general, most
  59.      monochrome display memory starts here, however, not all monochrome
  60.      cards have enough memory. Many of the older MDA adapters only have 1
  61.      page of display RAM. The info that came with your computer, display
  62.      card, or monitor should tell you for sure.
  63.       
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.           If you argument /c, the program will assume you have some color
  71.      video adapter with AT LEAST 32k of display memory beginning at segment
  72.      B800h. The program will then start it's buffer on page two of your
  73.      video ram, effectively saving conventional memory. I have tested this
  74.      on CGA, EGA, and VGA monitors, and have had no problems what so ever.
  75.      Again, if you are in doubt, check your paperwork.
  76.       
  77.           If you argument /s, the program will allocate 28K for the buffer
  78.      at the end of the resident portion of the program, thereby increasing
  79.      the amount of memory it consumes. Using either video buffer, the
  80.      program will keep about 1200 bytes for itself. Not very much at all.
  81.      On the other hand, if you can't use a video ram buffer, the program
  82.      will take in the neighborhood of 29K. Both of these numbers vary
  83.      depending on how much info you have in your environment.
  84.       
  85.           Obviously, using a video buffer saves a lot of memory, and seems
  86.      effective, however, there are draw backs. First of all, if you use a
  87.      program which uses multiple display pages, redirecting any output to a
  88.      file will more than likely cause the display to do all kinds of
  89.      strange things. Second, the program may do very strange things if you
  90.      attempt file output in any graphics mode. There may be other quirks
  91.      which surface when using the program with a video buffer. If you have
  92.      problems, you can always resort to using conventional memory, and I
  93.      have added a feature to make this even less painful!
  94.           
  95.           How many times have you loaded a resident program in memory, only
  96.      to find out it is stuck there. You finally end up having to re-boot
  97.      your computer to get it out. Well, I have designed this program to
  98.      unload it's self after it is installed, simply by running the program
  99.      with no arguments. So even if you have to use conventional memory, you
  100.      can easily load and unload this program as needed. You must remember
  101.      that if you attempt to unload PRINDIR after another program has
  102.      changed any of the interrupt vectors that prindir uses, you will not
  103.      be able to unload it until they are restored. PRINDIR will tell you a
  104.      message to this effect if this condition occurs.
  105.       
  106.           So by now you are wondering why even mess with this offending
  107.      buffer, and just have the data fall through right to an open disk
  108.      file. Well, this is yet another powerful feature of PRINDIR. The
  109.      program, every time it attempts a file write, will open the print
  110.      file, and continue to append data, as long as you want. But, if it
  111.      can't open the file, it will automatically create it, and then
  112.      continue to write to it. I worked with a shareware redirection program
  113.      that opened the file once, and then assumed it was there. But, if it
  114.      was deleted accidentally, the program didn't detect it, and the data
  115.      was written anyway to what would eventually become lost clusters. With
  116.      PRINDIR, this problem is eliminated.
  117.       
  118.           But there is yet another feature. You have the ability to change
  119.      the name of the output file!  When the program starts, it defaults to
  120.      the file name PRINDIRA.DAT which is created in the root directory on
  121.      drive C: Now if you use the specified key combinations, you can change
  122.      this to PRINDIRB.DAT, or PRINDIRC.DAT, etc... all the way through Z!
  123.      This will allow you to dump whole reports to different files. And you
  124.      can't ever lose data, because the program will not remove or truncate
  125.      existing files, it will only add data at the end.
  126.       
  127.           Thus, the main reason for the buffer is to hold the data you are
  128.      printing until the operating system is in a safe state, at which point
  129.      PRINDIR detects this and dumps the data to the file, and is then ready
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      for more. This concept is what allows the program to be a versatile as
  137.      it is.  One thing you should be aware of, is that may programs will
  138.      not allow the data prindir is holding in it's buffer to go to the file
  139.      until after the program has terminated. This is another reason for the
  140.      buffer, and a problem I am still working on. However, in the mean
  141.      time, I have added some code that will make file name specifier in the
  142.      FIL ? blink when data is waiting to be written. If the letter blinks
  143.      for an excessive amount of time, you will probably need to exit into
  144.      the operating system to dump the buffer to disk.
  145.       
  146.           Here is a quick summary of the keystrokes which control PRINDIR:
  147.       
  148.      Hold the LEFT SHIFT and ALT keys and press...
  149.       
  150.      S = direct output to the screen     P = direct output to the printer
  151.       
  152.      F = direct output to the file       N = advance file name indicator
  153.       
  154.                             C = clear the screen
  155.                
  156.       
  157.           I should also mention my preferred way of handling and locating
  158.      TSR (terminate and stay resident) programs in memory. This program
  159.      takes an unused interrupt and sets it to point to a special area in
  160.      its data segment. This way, the program can easily tell if it has been
  161.      installed, and at the same time, this interrupt points to all the data
  162.      needed to remove the program from memory. This is also the way I keep
  163.      the resident code so small. The only things resident are the new
  164.      interrupt handlers, and the resident data segment. Every thing else is
  165.      transient, and is released upon program exit. PRINDIR does exactly
  166.      this using interrupt 99h.
  167.       
  168.           If you have trouble using this program, or experience any
  169.      difficulties, please feel free to contact me so a solution may be
  170.      worked out. I anticipate people requesting that they be able to
  171.      argument their choice of buffer address, as well as a buffer size.
  172.      These are options I plan on in the future, however it is possible to
  173.      make minor changes to the buffer address and length through the DOS
  174.      patch program. For information on how to do this, please send me some
  175.      E-mail, and I will return the commands need to do this.
  176.       
  177.           PRINDIR was originally developed using Borland Turbo C version
  178.      2.0. After the program was operating properly, it was entirely re-
  179.      written using Borland's Turbo Assembler version 1.0.  De-bugging was
  180.      accomplished using Borland's Turbo Debugger version 1.0. Technical
  181.      information needed for manipulation of the operating system was
  182.      obtained from the DOS Programmers Reference 2nd Edition by Terry
  183.      Dettmann, published by QUE corporation.
  184.       
  185.      Turbo C, Turbo Assembler, and Turbo Debugger are registered trademarks
  186.      of Borland International, Inc.
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.